UTILITY PATENT APPLICATION 



HONORABLE COMMISSIONER OF 
PATENTS AND TRADEMARKS 
Washington D.G 2023 1 Case Docket No. 3350CH9D 

File No. (20734D) 
Client No. BOSSED 

Sir: 

Transmitted herewith for filing is the patent application of: 
INVENTOR(S): Ravi GANESAN and Kenneth HOBDAY 

FOR: ELECTRONIC BILLING WITH UPDATEABLE ELECTRONIC BILL SUMMARY 

o 

Enclosed are: 

[X] 54 pages of specification, claims, abstract 

[] Declaration & Power of Attorney. o< 
[X] Priority Claimed g>< 

u 



[X] 30 sheets of informal drawing. 
[] An assignment of the invention to _ 
and the assignment recordation fee. 
[] Certified copy of 



[] An associate power of attorney. 

[X] Information Disclosure Statement, Form PT04449 and reference. 



1146 Nineteenth Street, N.W. 
Fifth Floor 

Washington, DO. 20006-3404 
Telephone (202) 887-5555 
Facsimile (202) 2964682 
Date: September 1, 1999 



LALOS & KEEGAN 




Alfred A. Stadnicki 
Registration No. 30,226 



Docket No. : 33500-019D 
File No. : 20734D 
Client No. : BOSS-D 



ELECTRONIC BILLING WITH UPDATEABLE ELECTRONIC BILL SUMMARY 

RELATED APPLICATIONS 

This application is a continuation-in-part of pending 
Application Serial No. 09/017,169, entitled "Distributed Data 
Accessing Technique", filed February 2, 1998. 

FIELD OF THE INVENTION 

The present invention relates to electronic bill 
presentment and more particularly to electronic billing with 
updateable electronic bill summary presentment. 

BACKGROUND OF THE INVENTION 

There are two prevalent models for electronic bill 
presentment that are currently used in industry. The first is 
an aggregation model 10, which is shown in Figure 1. In its 
simplest form, the aggregation model 10 includes a customer 12, 
an aggregator 14, and a plurality of billers 16. The customer 
12 can be, for example, an individual person, a family, or a 
business. The aggregator 14 can be a financial institution (FI) 
such as, for example, a bank. Alternatively, the aggregator 14 
can be a separate entity which acts of behalf of a sponsor 18, 
which can also be an FI such as a bank. Each biller 16 can be 
of any billing institution type such as, for example, a local 
telephone company, a local electric company, a retail outlet, or 
a national long distance telephone company. 

Each biller 16 provides customer-related invoice data to 
the aggregator 14. The aggregator 14 serves as an intermediary 
between each biller 16 and the customer 12 by providing bill 
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presentment directly to the customer 12, potentially on behalf 
of the sponsor 18. 

There are two variants of the aggregation model 10 
resulting from the ownership, or "branding": of the presentation 
5 experience and the communication channel between the aggregator 
14 and the customer 12. In one variant, the aggregator 14 may 
offer aggregator-branding, thus totally owning both the 
presentation experience and the communication channel between 
the aggregator 14 and the customer 12. In the other variant, 

10 the aggregator 14 may offer sponsor-branding, thus staying 
"behind the scenes" in terms of the presentation experience and 
supporting the communication channel between the aggregator 14 
and the customer 12 on behalf of the sponsor 18. 

The second prevalent model for electronic bill presentment 

15 is a biller direct model 20, which is shown in Figure 2. In its 
simplest form, the biller direct model 20 includes a customer 12 
and at least one biller 16. In the biller direct model 20, each 
biller 16 retains the customer-related invoice data and the full 
relationship with the customer 12 (i.e., the presentation 

20 experience and the communication channel) . The customer 12 may 
have software for providing a capability similar to Web browser 
bookmarking so as to allow easy navigation between billers, and 
thus some level of virtual aggregation. However, there is no 
actual aggregation such as with the aggregator 14 of the 

25 aggregation model 10 described above. 

The above-described models present a dichotomy between a 
sponsor-centric view and a biller-centric view of bill 
presentment. That is, the aggregation model 10 allows the 
aggregator 14 and/or the sponsor 18 to use customer-related 

30 invoice data, bill presentment, and the communication channel 
between the aggregator 14 and the customer 12 for cross-selling 
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or other peripheral services. The biller direct model 20, on 
the other hand, insures that control of customer-related invoice 
data, bill presentment, and the communication channel between 
the biller 16 and the customer 12 remains with the biller 16. 
5 Also, neither of the above-described models adopts a truly 

customer-centric view. That is, neither of the above-described 
models allow a customer 12 to interact directly with individual 
billers 16 while retaining the benefits of interacting with a 
single aggregator 14 such as, for example, the ability to retain 
10 a single authentication and log-in procedure and a common bill 
presentation framework. Further, neither of the above-described 
Q models allow a customer 12 to retain the benefits of interacting 
Jp with a single aggregator 14 while allowing the aggregator 14, 
€9 billers 16, and sponsor 18 to retain certain preferences such 
^[15 as, for example, the ability to retain control of customer- 
m related data and a communication channel with each customer 12. 
J Accordingly, it would be desirable to provide a more flexible 
^ data accessing technique. 

OBJECTS OF THE INVENTION 

=£20 One object of the present invention is to provide a 

distributed data accessing technique that allows a customer to 
interact directly with individual billers while retaining the 
benefits of interacting with a single aggregator. 

Another object of the present invention is to provide a 
25 distributed data accessing technique that allows a customer to 
retain the benefits of interacting with a single aggregator 
while allowing the aggregator, billers, and sponsor to retain 
control of customer-related data and a communication channel 
with each customer. 
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Another object of the present invention is to provide a 
real time distributed data accessing technique that ensures 
payments of the correct bill amount. 

The above-stated objects, as well as other objects, 
5 features, and advantages, of the present invention will become 
readily apparent from the following detailed description which 
is to be read in conjunction with the appended drawings. 

SUMMARY OF THE INVENTION 

In accordance with the invention, an electronic bill 
10 payment network includes a plurality of biller network stations 
p each associated with a different biller, a plurality of user 

network stations each associated with a different user, and a 
fr| central network station. Real time network communications is 

used to transfer information between the applicable user network 
CP15 station, applicable biller network station and the central 
: network station. As used herein, the phase "real time" is 
« defined to mean during a single on-line session involving a user 
..J seeking to view and, if desired, pay a bill. 

J More particularly, a first user network station, 

*220 associated with a first of the users, is operable, in real time, 
to transmit information relevant to an amount of an available 
bill. The transmitted information could, for example, be a gas 
or electric meter reading, of the amount of product ordered or 
used etc., which is required to determine, e.g. compute, the 
25 amount of the bill. Alternatively, the relevant information 
could be indicative of a disputed portion of a previously 
computed bill amount. In the latter case, the amount which will 
be determined could, for example, reflect a requested adjustment 
to the previously computed bill amount. 
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A first biller network station, associated with a first of 
the billers, is operable, in real time, to receive the 
transmitted information and to determine the amount of the 
available bill based upon the received information. As discussed 
above, this may be either a first determination of the bill 
amount or a determination of an adjusted bill amount. 

The central network station is operable, again in real 
time, to receive the determined amount of the available bill. 
The central station is also operable to receive a pay 
instruction transmitted by the first user network station, and 
to direct payment of the determined amount of the bill based 
e upon the transmitted instruction to pay that bill. The pay 
« instruction and the determined amount may be transmitted from 
IB either the user or biller network station in a single or 
J15 separate communications, or respectively from the user and 
-51 biller network stations. 

a Preferably, a database stores bill availability information 

^ identifying available bills of the different billers for the 
O different users, and the central network station is operable to 
^20 transmit the bill availability information to the user network 
S stations. The bill availability information may beneficially 
include the amount of each of the identified bills. If so 
desired, the availability information may also include other 
bill summary information, although this is not mandatory. 
Advantageously, the transmitted stored availability information 
includes an indicator which identifies those of the identified 
available bills which require information relevant to 
determining the total amount of those bills. The database may 
also be configured to store, typically under the direction of 
the central station processor, any previously determined bill 
amount and the newly determined bill amount. 
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In an exemplary operating sequence, the central station 
transmits two or more of the available bills to the first user 
network station. The first user network station is operable to 
receive the transmitted bill availability information. 
5 Normally, this information is displayed by the first user 
station to the first user. The first user station is also 
operable to select a particular bill from the identified bills, 
typically based upon an input from the user. A request for the 
applicable bill is then transmitted by the first user station 
10 based upon the selection. If the selected bill is a bill of a 
first biller for the first user, the network station associated 
with the first biller operates, in real time, to transmit either 
^ a request for the information relevant to the bill amount or the 
0] available bill including a previously computed bill amount, as 
^15 applicable. Preferably, the central station also receives a 
fijj communication, from the first biller station, indicative of the 
available bill having been requested from the first biller. 

It will also be recognized by those skilled in the art, 
p that the invention is easily implemented using computer 
^20 software. More particularly, software can be easily programmed, 
%s using routine programming skill, based upon the description of 
the invention set forth herein and stored on a computer readable 
storage medium which is readable by a computer processor of the 
applicable system component, e.g. a user , a biller or a central 
25 network station to cause the processor to operate such that the 
particular station operates in the manner described above. 

BRIEF DESCRIPTION OF THE DRAWINGS 

In order to facilitate a fuller understanding of the 
present invention, reference is now made to the appended 
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drawings. These drawings should not be construed as limiting 
the present invention, but are intended to be exemplary only. 

Figure 1 is an aggregation model for electronic bill 
presentment . 

5 Figure 2 is a biller direct model for electronic bill 

presentment . 

Figure 3 is an infrastructure diagram of a distributed 
database entity in accordance with the present invention. 

Figure 4 is a schematic diagram of an electronic bill 
10 presentment and payment system in accordance with the present 
invention. 

Figure 5 is a schematic diagram of an electronic payment 
and customer service (EPCS) entity in accordance with the 
present invention . 
15 Figure 6 is a schematic diagram of the electronic bill 

presentment and payment system shown in Figure 4, extended to 
include certain associated directly related systems. 

Figure 7 is a schematic diagram of the electronic bill 
presentment and payment system shown in Figure 4, extended to 
20 include certain associated indirectly related systems. 

Figure 8 is a schematic diagram of the electronic bill 
presentment and payment system shown in Figure 4, extended to 
include certain associated customer care entities. 

Figure 9 is a schematic diagram of the electronic bill 
25 presentment and payment system shown in Figure 4, extended to 
include a centralized customer care entity. 

Figure 10 is a flowchart diagram showing initial sign-on 
data and message flows between a user entity and a banking 
entity in the electronic bill presentment and payment system 
30 shown in Figure 4 . 
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Figure 11 is a flowchart diagram showing sign-on and 
authentication data and message flows between a user entity, a 
banking entity, and an EPCS entity in the electronic bill 
presentment and payment system shown in Figure 4 . 

5 Figure 12 is a flowchart diagram showing bill availability 

data and message flows between a user entity, a banking entity, 
and an EPCS entity in the electronic bill presentment and 
payment system shown in Figure 4. 

Figure 13A is a flowchart diagram showing billing entity 

10 presentment data and message flows between a user entity, a 
billing entity, and an EPCS entity in the electronic bill 
presentment and payment system shown in Figure 4. 

Figure 13B is a flowchart diagram showing billing 
aggregator bill presentment data and message flows between a 

15 user entity, a billing entity, an EPCS entity, and an 
established billing aggregator in the electronic bill 
presentment and payment system shown in Figure 4 . 

Figure 13C is a flowchart diagram showing alternative 
system bill presentment data and message flows between a user 

20 entity, an EPCS entity, and an alternative bill presentment and 
payment system in the electronic bill presentment and payment 
system shown in Figure 4. 

Figure 14 is a flowchart diagram showing bill payment data 
and message flows between a user entity, an EPCS entity, and a 

25 billing entity in the electronic bill presentment and payment 
system shown in Figure 4 . 

Figure 15 is a flowchart diagram showing bill remittance 
and debiting data and message flows between an EPCS entity and a 
billing entity and a banking entity in the electronic bill 

30 presentment and payment system shown in Figure 4. 
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Figure 16 shows an example of a branded interface having a 
sign-on request prompt that includes a username field and a 
password field, in accordance with the present invention. 

Figure 17 shows an example of a banking entity home page, 
including a "view bills'' icon, a "view checking account" icon, 
and a "view savings account" icon, in accordance with the 
present invention . 

Figure 18 shows a first modified banking entity home page 
having a frame presenting new bill availability data, in 
accordance with the present invention. 

Figure 19 shows a second modified banking entity home page 
having a frame presenting detailed bill data, in accordance with 
the present invention. 

Figure 2 0 is a flowchart diagram showing customer service 
data and message flows between a centralized customer service 
center, and an EPCS entity, a billing entity, and a banking 
entity in the electronic bill presentment and payment system 
shown in Figure 4 . 

Figure 21 is a flowchart diagram showing bill availability 
data and message flows between a user entity, a banking entity, 
and an EPCS entity in the electronic bill presentment and 
payment system shown in Figure 4, modified to allow dynamic 
updating of bill summary information at the EPCS entity, in 
accordance with the present invention. 

Figure 22A shows a modified banking entity home page having 
a frame presenting new bill availability data for a subscriber, 
with certain data available from the biller only after a meter 
reading, is furnished by the subscriber in accordance with the 
present invention. 
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Figure 22B shows another modified banking entity home page 
having a frame presenting new bill availability data, including 
total bill amounts, for a subscriber, with certain data 
available from the biller only after a meter reading is 
furnished by the subscriber in accordance with the present 
invention. 

Figure 23A is a flowchart diagram showing billing entity 
presentment data after receipt of a meter reading from the 
subscriber and message flows between a user entity, a billing 
entity and an EPCS entity in the electronic bill presentment and 
payment system shown in Figure 4 for a subscriber, with bill 
summary information being dynamically updated at the EPCS, in 
accordance with the present invention. 

Figure 23B is a flowchart diagram showing billing entity 
presentment data after receipt of a message indicating a portion 
of an originally presented bill is disputed by the subscriber 
and message flows between a user entity, a billing entity and an 
EPCS entity in the electronic bill presentment and payment 
system shown in Figure 4 for a subscriber, with bill summary 
information being dynamically updated at the EPCS, in accordance 
with the present invention. 

Figure 24A shows another modified banking entity home page 
having a billing entity frame presenting detailed bill data to a 
first subscriber after the subscriber has provided a meter 
reading, in accordance with the present invention. 

Figure 2 4B shows another modified banking entity home page 
having a billing entity frame presenting detailed bill data 
which can be revised to reflect disputed portions of the bill, 
in accordance with the present invention. 
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Figure 24C shows the modified banking entity home page of 
Figured 24B having a billing entity frame presenting modified 
detailed bill data indicating that a portion of the bill is 
disputed, in accordance with the present invention. 

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT 

Referring to Figure 3, there is shown an infrastructure 
diagram of a distributed database entity 30 in accordance with 
the present invention. The distributed database entity 30 
comprises a database component 32 and a plurality of message 
interfaces 34-40 for facilitating communication between the 
database component 32 and other distributed database entities 
and system components. The database component 32 typically 
contains data that is controlled or "owned" by the controller or 
"owner" of the distributed database entity 30. For example, if 
the distributed database entity 30 is owned by a financial 
institution (FI) such as a bank, then the database component 32 
could contain information such as checking and savings account 
balances. It should be noted, however, that the database 
component 32 can also contain data from other distributed 
database entities and system components, as will be described in 
detail below. 

The plurality of message interfaces 34-40 includes an 
internal message interface 34, an external message interface 36, 
a partner message interface 38, and a customer care message 
interface 40. The internal message interface 34 defines 
messages that are used to communicate and query data between the 
given distributed database entity 30 and other distributed 
database entities, or other system components having an internal 
message interface. For example, in a bill presentment and 
payment system, communication between a banking entity and a 
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billing entity may be required. The external message interface 
36 defines messages that are used to communicate and query data 
between the given distributed database entity 30 and any 
existing system (s) that are directly related to the given 
distributed database entity 30. For example, an FI such as a 
bank can have an existing direct deposit account (DDA) system. 
The partner message interface 38 defines messages that are used 
to communicate and query data between the given distributed 
database entity 30 and any existing system (s) that are 
indirectly related to the given distributed database entity 30. 
For example, in a bill presentment and payment system, 
communication with an established billing aggregator may be 
necessary to satisfy customer demands. The customer care 
message interface 40 defines messages that are used to 
communicate and query data between the given distributed 
database entity 30 and a customer care entity. For example, in 
a bill presentment and payment system, a billing entity may 
allow a third party to access bill data in order to provide 
feedback to bill customers. It should be noted that all of the 
above-described interfaces will be described in greater detail 
below. 

Referring to Figure 4, there is shown a schematic diagram 
of a versatile electronic bill presentment and payment system 50 
in accordance with the present invention. The system 50 
comprises a user entity 52, a banking entity 54, a billing 
entity 56, and an electronic payment and customer service (EPCS) 
entity 58. For purposes of this detailed description, the user 
entity 52, the banking entity 54, the billing entity 56, and the 
EPCS entity 58 are each distributed database entities 30 as 
defined above. Thus, the user entity 52, the banking entity 54, 
the billing entity 56, and the EPCS entity 58 each has a 
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database component 32, an internal message interface 34, an 
external message interface 36, a partner message interface 38, 
and a customer care message interface 40. It should be noted, 
however, that the user entity 52, the banking entity 54, the 
5 billing entity 56, and the EPCS entity 58 are not required to 
have a database component 32, an internal message interface 34, 
an external message interface 36, a partner message interface 
38, and a customer care message interface 40. That is, the user 
entity 52, the banking entity 54, the billing entity 56, and the 
10 EPCS entity 58 are only required to have an internal message 
interface 34 so that communications can take place between each 
^ entity. 

J^J At this point it should be noted that, although only a 

m single user entity 52, banking entity 54, billing entity 56, and 
As EPCS entity 58 is shown in the system 50, it is common to have a 
IJj plurality of such entities in an actual versatile electronic 
s " bill presentment and payment system in accordance with the 
"!? present invention . 

O As previously described, an internal message interface 34 

^20 defines messages that are used to communicate and query data 
€l between distributed database entities. Thus, since the user 
entity 52, the banking entity 54, the billing entity 56, and the 
EPCS entity 58 are all distributed database entities, they all 
communicate through internal message interfaces 34. The 
25 communications are performed over interconnections 60, which can 
be electrical wire, optical fiber, or microwave-based 
interconnections . 

At this point it should be noted that each internal message 
interface 34, as well as each external message interface 36, 
30 partner message interface 38, and customer care message 
interface 40, can be implemented using any number of existing 
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message-based communication systems such as, for example, a 
TCP/IP message-based communication system running on the 
infrastructure of the internet. Alternatively, the internal 
message interfaces 34 , the external message interfaces 36, the 
partner message interfaces 38, and the customer care message 
interfaces 40 could be implemented with proprietary messaging 
software on a private network or intranet. It should also be 
noted that there are no requirements as to the nature of the 
messaging protocol, or any middleware used to support the 
messaging. 

The user entity 52 is typically a personal computer (PC) 
that is directly connected to the system 50, or is connected to 
the system 50 through a network server. Thus, the database 
component 32 associated with the user entity 52 can be located 
on the PC (e.g., a traditional "fat" client), or on the network 
server (e.g., an HTML browser client). It should be noted that 
the database component 32 associated with the user entity 52 can 
also be located in one of the other distributed database 
entities, which can download data to the user entity 52 (e.g., a 
Java client) . It should also be noted that the database 
component 32 associated with the user entity 52 can be 
distributed among all three of the above-listed locations, owing 
to the distributed nature of each database component 32. Thus, 
each database component 32 should not be thought of as a single, 
monolithic database. Rather, each database component 32 is 
better described as a distributed repository of data categorized 
by the entity that "owns" the data. 

Wherever it is located, the database component 32 
associated with the user entity 52 stores data that is related 
to the type of user interface (UI) that is being presented to a 
subscriber of the system 50. For example, the database 
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component 32 associated with the user entity 52 can store data 
that is related to the particular type of presentation 
technology being used (e.g., a "fat" client, an HTML browser 
client, or a Java client), a specific application, or a 
5 particular version. The database component 32 associated with 
the user entity 52 can also store data that is related to a 
particular computing session such as, for example, the existence 
of a computing session and/or the duration of a computing 
session. The database component 32 associated with the user 
10 entity 52 can further store subscriber authentication data, 
which is described in detail below, 
o The main function of the user entity 52 is to build a UI 

fi using data obtained from the other distributed database 
ffl entities, and then present the UI to a subscriber of the system 
~J15 50. The presentation of the UI to a subscriber is dependent 
«. a upon the particular type of presentation technology being ufsed 
$ (e.g., a "fat" client, an HTML browser client, or a Java 

>L client) . For example, a UI for a Java client requires that 
O presentation data be downloaded from one of the other 
lfg.0 distributed database entities. 

^ Other functions of the user entity 52 include storing 

certain data locally so as to facilitate off-line editing and 
viewing, maintaining a state in a connectionless environment 
(e.g., an HTTP environment), and sensing the availability of 

25 software updates and managing their subsequent application. All 
of these functions depend on the nature of the client (e.g., a 
"fat" client, an HTML browser client, or a Java client) . As 
previously indicated, another function of the user entity 52 
includes storing subscriber authentication data (e.g., a 

30 security ticket) that is used to gain access to other 
distributed database entities in the system 50. 
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The banking entity 54, which is typically an FI such as, 
for example, a bank, is generally viewed as a primary point of 
presence for a subscriber to the system 50, typically providing 
an appearance of aggregation to the subscriber. This view is 
held primarily due to the trust that consumers typically place 
in a bank brand, and the fact that bank customers who already 
bank online are also likely to want to receive bills online. 
Thus, in the following discussion, the banking entity 54 is 
assumed to be the aggregator of the system 50. It should be 
noted, however, that any one of the other entities could also be 
the aggregator of the system 50 in accordance with the present 
invention. There are several factors which can be used to 
determine aggregator status such as, for example, market clout. 

The banking entity 54 typically gains access to the system 
50 through a network server. Thus, the database component 32 
associated with the banking entity 54 can be located in the 
network server. It should be noted that the database component 
32 associated with the banking entity 54 can also be located in 
a system associated with the banking entity 54 such as, for 
example, a DDA system. Such a DDA system could be accessed 
through the external message interface 36 of the banking entity 
54, as described in detail below. It should further be noted 
that the database component 32 associated with the banking 
entity 54 can also be located in one of the other distributed 
database entities, or be distributed among many of the above- 
mentioned locations, owing to the distributed nature of each 
database component 32. 

Wherever it is located, the database component 32 
associated with the banking entity 54 stores bank-specific 
subscriber profile data profile such as, for example, subscriber 
names and addresses and subscriber account numbers. The 
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database component 32 associated with the banking entity 54 can 
also store account information such as, for example, static 
account information (e.g., lease rate, principle) , and dynamic 
account information (e.g., balance). The database component 32 
associated with the banking entity 54 can further store profile 
data specifically associated with the FI such as, for example, 
graphics, business rules, banking-related transaction histories, 
and aggregation relationships such as those between the FI and 
billers . 

Since it is likely that the system 50 will be used with 
existing banking systems such as, for example, an existing DDA 
system, one of the main functions of the banking entity 54 is 
the continuation of current banking and bill payment 
functionality including the maintaining of customer profiles and 
already existing interfaces. In its role as aggregator, the 
banking entity 54 also provides data to the user entity 52 to be 
used for the creation of a navigation portion of a UI. For an 
HTML browser client, this data would be used to create a 
navigation frame, but not a content specific frame. It should 
be noted that the banking entity 54 can also provide data to the 
user entity 52 to be used for the creation of a UI for 
traditional banking and bill payment. 

Since the banking entity 54 is generally viewed as the 
primary point of presence for a subscriber to the system 50, the 
banking entity 54 also functions as the likely, but not 
exclusive, entry point for subscriber sign-on. Thus, the 
banking entity 54 typically controls the sign-on and 
authentication procedures for subscribers through the user 
entity 52. It should be noted that the banking entity 54 
typically works in conjunction with the EPCS entity 58 in 
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controlling the authentication procedure, as described in detail 
below. 

Another function of the banking entity 54 includes tracking 
bank related events and storing them in an event tracking 
database, which is typically associated with the EPCS entity 58, 
as also described in detail below. 

The billing entity 56 is typically a biller such as, for 
example, a utility company. The billing entity 56 typically 
gains access to the system 50 through a network server. Thus, 
the database component 32 associated with the billing entity 56 
can be located in the network server. It should be noted that 
the database component 32 associated with the billing entity 56 
can also be located in a system associated with the billing 
entity 56 such as, for example, a legacy billing system. Such a 
legacy billing system could be accessed through the external 
message interface 36 of the billing entity 56, as described in 
detail below. It should further be noted that the database 
component 32 associated with the billing entity 56 can also be 
located in one of the other distributed database entities, or be 
distributed among many of the above-mentioned locations, owing 
to the distributed nature of each database component 32. 

Wherever it is located, the database component 32 
associated with the billing entity 56 stores biller-specif ic 
subscriber profile data such as, for example, subscriber names 
and addresses and subscriber account numbers and types (e.g., 
business vs. residential phone line). The database component 32 
associated with the billing entity 56 also stores billing data 
for use by the user entity 52 in building the UI for the 
subscriber. The billing data can include bill availability 
data, detailed billing data, ads and other cross-sale displays 
and links, and bill payment terms and conditions. 



18 



Docket No.: 33500-019D 
File No. : 20734D 
Client No. : BOSS-D 

The database component 32 associated with the billing 
entity 56 can also store biller transaction history such as, for 
example, bill data manipulation (e.g., viewing, searching, 
sorting), and cross-sell events. The database component 32 
associated with the billing entity 56 can further store biller 
profile data such as, for example, graphics, business rules, and 
relationships with aggregators such as banks. 

The main function of the billing entity 56 is to provide 
billing data to the user entity 52 for use in creating the UI 
for the subscriber. The billing entity 56 also provides bill 
availability data to an aggregator database, whether it is 
located in the banking entity 54, the EPCS entity 58, or another 
entity, to provide notice of bill availability to subscribers. 
The billing entity 56 can also access legacy billing systems 
through the external message interface 36 of the billing entity 
56, as indicated above. 

Another function of the billing entity 56 includes tracking 
biller-related events and storing them in an event tracking 
database, which is typically associated with the EPCS entity 58, 
as described in detail below. 

The EPCS entity 58 can generally be described in terms of a 
data processing system 70, such as shown in Figure 5. The data 
processing system 70 preferably comprises at least one processor 
(P) 72, memory (M) 74, and input/output (I/O) interface 76, 
which are connected to each other by a bus 78, for implementing 
the functions of the EPCS entity 58, as described in detail 
below. 

Referring again to Figure 4, the EPCS entity 58 typically 
gains access to the system 50 through a network server. Thus, 
the database component 32 associated with the EPCS entity 58 can 
be located in the network server. It should be noted that the 
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database component 32 associated with the EPCS entity 58 can 
also be located in a system associated with the EPCS entity 58 
such as, for example, a legacy aggregating system. Such a 
legacy aggregating system could be accessed through the external 
5 message interface 36 of the EPCS entity 58, as described in 
detail below. It should further be noted that the database 
component 32 associated with the EPCS entity 58 can also be 
located in one of the other distributed database entities, or be 
distributed among many of the above-mentioned locations, owing 
10 to the distributed nature of each database component 32. 

Wherever it is located, the database component 32 
□ associated with the EPCS entity 58 stores bill payment-specific 
H subscriber profile data such as, for example, subscriber names 
HI and addresses, subscriber DDA account numbers, and subscriber 
~A5 credit ratings. The database component 32 associated with the 
b Jj EPCS entity 58 also stores bill payment warehouse data such as, 

sks; 

s for example, user-specific payees, single occurrence payments, 
% and recurring payments /models . 

P As previously described, both the banking entity 54 and the 

]?2Q billing entity 56 track and store events in an event tracking 
database. This event tracking database is typically located in 
the database component 32 associated with the EPCS entity 58. 
The event tracking data that is stored typically comprises event 
summaries and links to other databases, perhaps residing at 
25 other entities, which provide event details and/or an audit 
trail . 

The database component 32 associated with the EPCS entity 
58 also stores bill payment transaction histories, and system 
subscriber profile data such as, for example, metadata about 
30 subscribers and metadata about subscribers 1 relationships to 
other entities (e.g., a list of billers that a subscriber has 



20 



Docket No.: 33500-019D 
File No. : 20734D 
Client No. : BOSS-D 



enabled) . The database component 32 associated with the EPCS 
entity 58 further stores billing-related profile information on 
the system aggregator and billers such as, for example, metadata 
about billing arrangements (e.g., flat rate, per subscriber, 
5 event-driven, etc.), and aggregation data such as, for example, 
new bill availability and messages or special announcements 
available from the billing entity 56. The database component 32 
associated with the EPCS entity 58 still further stores security 
data such as, for example, required sign-on information and 
10 macro-level authorizations. The database component 32 

associated with the EPCS entity 58 additionally stores customer 
service data such as, for example, FAQ ! s, FI and biller contact 
f* information, and problem resolution data. 

£0 The EPCS entity 58 is the glue that holds the distributed 

,15 database entities together. The EPCS entity 58 accomplishes 
0] this by functioning as an integration agent by maintaining bill 
s payment profiles and warehouse data, aggregating bill 
availability and status data (but not bill content or 
O presentation) , and maintaining an event tracking database (or 
li&0 audit trail) that can be accessed by all of the database 
C? entities . Also, in order to facilitate a single point of sign- 
on, the EPCS entity 58 functions as the authentication gate 
keeper. This doesn't mean to imply that the EPCS entity 58 
necessarily maintains user identification numbers and/or 
25 passwords. However, it does imply that the EPCS entity 58 
accepts sign-on requests and doles out authentication "tickets" 
in response, in conjunction with the banking entity as described 
above . 

It should be noted that, like user identification numbers 
30 and passwords, other data elements, like event details, may end 
up being virtually aggregated by the EPCS entity 58, but may 
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still physically reside in a distributed manner across several 
of the database entities. 

It should also be noted that the EPCS entity 58 may also 
route e-mail messages to and from the various database entities, 
as well as store e-mail messages sent to and from the various 
database entities . 

As previously described, an internal message interface 34 
defines messages that are used to communicate and query data 
between distributed database entities. As also previously 
described, each internal message interface 34 can be implemented 
using any number of existing message-based communication 
systems, or with proprietary messaging software on a private 
network or intranet. Furthermore, the message specification or 
file format can be either standard (i.e., open) or proprietary. 
With this mind, the following types of messages are examples of 
messages which may be employed to implement an internal message 
interface 34 in accordance with the present invention. 

Depending upon the nature of the presentation technology 
being used (e.g., a "fat" client, an HTML browser client, or a 
Java client), the user entity 52 may need to process an internal 
message to store a security ticket for later use in gaining 
access to other distributed database entities in the system 50. 
The user entity 52 may also need to process an internal message 
to update any resident software. The user entity 52 may further 
need to process an internal message containing various types of 
information (assuming a push model) . The user entity 52 may 
additionally need to process internal e-mail messages such as, 
for example, those for receiving data from other database 
entities . 

The banking entity 54 will process an internal message to 
add/update/delete/retrieve FI branding information, as well as 
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an internal message to add/update/delete an entry from a list of 
billers that have been aggregated. The banking entity 54 will 
also process an internal message to activate a subscriber for 
home banking via a messaging protocol, which can be an existing 

5 messaging protocol such as, for example, OFX or a batch process. 
The banking entity 54 will further process an internal message 
to query/update bank subscriber profile data for purposes of 
customer care. The banking entity 54 will still further process 
an internal message to query bank transaction history for 

10 customer care and for linking to the event tracking database. 
The banking entity 54 will still further process an internal 

0 message to retrieve a list of billers available under the FI 
fi sponsor umbrella. An alternative to this is to place the list 
CO of billers available under the FI sponsor umbrella in an 
Cl5 aggregation database. However, placing the list of billers 

01 available under the FI sponsor umbrella allows the EPCS entity 
« 58 to tailor the list by FI sponsor. The banking entity 54 will 
™J additionally process internal e-mail messages such as, for 
O example, those for sending data to other database entities, 
LH20 receiving data from other database entities, and broadcasting 
* data to other database entities. 

The billing entity 56 will process an internal message to 
add/update/delete/retrieve biller branding information, as well 
as an internal message to activate a subscriber for electronic 

25 bill presentment via a messaging protocol, which can be an 
existing messaging protocol such as, for example, OFX or a batch 
process. The billing entity 56 will also process an internal 
message to retrieve bill availability data, retrieve bill detail 
data, and retrieve bill presentation specifications or content. 

30 For example, the retrieved data could be URL links to ads and 
notices, HTML data, or OFX data. The billing entity 56 will 
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further process an internal message to query/update biller 
subscriber profile data for purposes of customer care. The 
billing entity 56 will still further process an internal message 
to query biller transaction history for customer care and for 
5 linking to the event tracking database. The billing entity 56 
will additionally process internal e-mail messages such as, for 
example, those for sending data to other database entities, 
receiving data from other database entities, and broadcasting 
data to other database entities. 
10 The EPCS entity 58 will process internal event tracking 

messages. Such event tracking messages are used to gain access 
q to two types of information in the event tracking database: 
*| summary data and a link to another database entry that can 
m provide more detail. Such detail includes subscriber enrollment 
: J|5 data, subscriber service activation data (e.g., biller, bill 
CP payment, banking, etc.), sign-on data, bill availability data, 
„ s bill viewed data, bill payment generated data (optionally 
;^ associated with presented bill data), subsequent bill payment 
o events data (e.g., submitted, processed, failed, cleared, 
J|o remittance received by biller, etc.), cross-sell events data 
€1 (e.g., ad/offer viewed, ad/offer clicked, product/service 
purchased) , terms & conditions viewed data, e-mail 
created/read/deleted data. 

The EPCS entity 58 will also process an internal messages 
25 related to subscriber profile data such as, for example, to 
add/modify/delete/read subscriber profile data, often as a 
function of the events listed above (e.g., enrollment, 
activation, etc. ) . 

The EPCS entity 58 will also process internal security 
30 messages. Such internal security messages may relate to 
authentication, which result in the EPCS entity 58 issuing a 
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security ticket. It should be noted that an authentication 
request does not have to come as a result of a subscriber 
"surfing" to the network server of the banking entity 54. It 
may be initiated if a subscriber tries to gain access to the 
5 billing entity 56, and thereby not even contacting the banking 
entity 54. The point being that with a security ticket a 
subscriber is generally allowed to freely traverse any database 
entity in the system 50 without going through repeated sign-on 
procedures . 

10 An internal security message may also relate to macro-level 

authorization, wherein a security ticket may contain the 

g*% credentials to allow a subscriber access to a particular billing 
entity, but doesn't address micro-level authorization issues 

igt such as allowed operations. 

,15 An internal security message may also relate to getting a 

Cm security ticket without authentication. Such a message will 

;wpss 

s " originate from a trusted party (e.g., an FI performing its own 
w authentication) . Therefore, a security ticket is provided 
Q without performing an authentication. 

J7?0 It should be noted that the use of a security ticket 

€1 enables, but does not mandate, a single sign-on procedure. In 
other words, a database entity such as, for example, the billing 
entity 56 may, for whatever reason, require additional 
authentication information. 
25 The EPCS entity 58 will further process internal messages 

relating to aggregation data. For example, an EPCS entity 58 
will process an internal message to create a link to summary or 
detailed bill information, or to create a link to message, 
notice, ad, or some other kind of non-bill information that is 
30 available from the billing entity 56. 
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The EPCS entity 58 will still further process an internal 
message to query/update bill payment transaction history for 
purposes of customer care. 

The EPCS entity 58 will additionally process internal e- 
5 mail messages such as, for example, those associated with 
routing e-mail, picking-up e-mail f and querying and e-mail 
mailbox. 

The EPCS entity 58 may also process internal messages 
related to data mining. Such messages are handled very 
10 carefully with respect to privacy, perhaps even providing an ACL 
or other mechanisms to ensure privacy. The results of such 
p messages may be delivered out of band (e.g., by batch). 

As previously described, an external message interface 36 
CO defines messages that are used to communicate and query data 
,Jl5 between a given distributed database entity 30 and any existing 
system (s) that are directly related to the given distributed 
T database entity 30. As also previously described, each external 
^ message interface 36 can be implemented using any number of 
O existing message-based communication systems, or with 
;^20 proprietary messaging software on a private network or intranet, 
tfl Furthermore, the message specification or file format can be 
either standard (i.e., open) or proprietary. 

Referring to Figure 6, there is shown a schematic diagram 
of the versatile electronic bill presentment and payment system 
25 50, along with some associated directly related systems. The 
associated directly related systems comprise a desktop database 
80, a DDA system 82, a legacy billing system 84, and a legacy 
remittance system 86. The communications between the various 
database entities and their associated directly related systems 
30 are performed over interconnections 88, which can be electrical 
wire, optical fiber, or microwave-based interconnections. 
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Depending upon the nature of the presentation technology 
being used (e.g., a "fat" client, an HTML browser client, or a 
Java client), the user entity 52 may need to process an external 
message in order to communicate with an existing system such as, 
for example, the desktop database 80. To support such a legacy 
system, it may be necessary to implement the external message 
interface 36 of the user entity 52 in the context of an 
existing, and possibly extended, protocol specification, such as 
Gold, NPC, or OFX. 

The banking entity 54 will process external messages to and 
from an existing system such as, for example, the DDA system 82 
in order to query and update information such as, for example, 
subscriber profile data, subscriber account data, out-of-band 
(e.g., ATM) account activity, and statement history. It's also 
conceivable that the banking entity 54 would need to interface 
with other banking systems (e.g., stops). Thus, the external 
message interface 36 of the banking entity 54 is a key feature 
of the versatile electronic bill presentment and payment system 
50. 

The billing entity 56 will process external messages to and 
from an existing system such as, for example, the legacy billing 
system 84 in order to query and update information such as, for 
example, subscriber profile data, subscriber account data, 
account activity, and statement history. Most of this data is 
industry, if not biller, specific. Thus, the external message 
interface 36 of the billing entity 56 is a key feature of the 
versatile electronic bill presentment and payment system 50. 

The EPCS entity 58 will process external messages to and 
from an existing system such as, for example, the legacy 
remittance system 86. The legacy remittance system 86 could be, 
for example, ACH, RPP, RPS, or Direct Send. 



Docket No.: 33500-019D 
File No. : 20734D 
Client No. : BOSS-D 

As previously described, a partner message interface 38 
defines messages that are used to communicate and query data 
between a given distributed database entity 30 and any existing 
system (s) that are indirectly related to the given distributed 
database entity 30. As also previously described, each partner 
message interface 38 can be implemented using any number of 
existing message-based communication systems, or with 
proprietary messaging software on a private network or intranet. 
Furthermore, the message specification or file format can be 
either standard (i.e., open) or proprietary. 

Referring to Figure 7, there is shown a schematic diagram 
of the versatile electronic bill presentment and payment system 
50, along with some associated indirectly related systems. The 
associated indirectly related systems comprise a personal 
finance system 90, a banking system 92, an established billing 
aggregator 94, and an alternative bill presentment and payment 
system 96, The communications between the various database 
entities and their associated indirectly related systems are 
performed over interconnections 98, which can be electrical 
wire, optical fiber, or microwave-based interconnections. 

Depending upon the nature of the presentation technology 
being used (e.g., a "fat" client, an HTML browser client, or a 
Java client), the user entity 52 may need to process a partner 
message in order to communicate with a partner such as, for 
example, the personal finance system 90. The personal finance 
system 90 could be, for example, a personal financial manager 
(PFM) software package such as, for example, Quicken or Money. 

The banking entity 54 will process partner messages to and 
from a partner such as, for example, the banking system 92. 
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The billing entity 56 will process partner messages to and 
from a partner such as, for example, the established billing 
aggregator 94. Such a partner relationship may be required if a 
large group of subscribers are using the established billing 
5 aggregator 94, and thereby have the leverage to demand that all 
of their bills come through the established billing aggregator 
94. The established billing aggregator 94 is essentially 
treated as a proxy for the billers that it represents. Thus, 
subscribers to the established billing aggregator 94 will have 
10 equal footing as subscribers to the present system 50. This 
means that subscribers to the established billing aggregator 94 
will receive the same event tracking, customer service, and 
payment processing functionality as subscribers to present 
g| system 50. Of course, to gain the additional functionality 
y}5 provided by the present system 50, the established billing 
CH aggregator 94, or someone acting on their behalf, will need to 
g " provide the same programming support that is required of any 
^ biller participating in the present system 50. 

O To present a bill generated by the established billing 

"f20 aggregator 94, the present system 50 would, for example, receive 
S bill availability data and the URL of a web server of the 
established billing aggregator 94, and the billing entity 56 
would then point to the web server of the established billing 
aggregator 94 to get an HTML presentation of detailed bill data. 
25 In this scenario, the partner message interface 38 would be 
essentially the same as an internal message interface 34, but 
possibly with added bulk transfer capability. 

The EPCS entity 58 will process partner messages to and 
from a partner such as, for example, the alternative bill 
30 presentment and payment system 96. Such a partner relationship 
may be required if a billing entity 56 has a subscriber base 
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that is split between using the present system 50 and the 
alternative bill presentment and payment system 96. In such a 
scenario, the present system 50 could function as a billing 
aggregator for the alternative bill presentment and payment 
system 96, and vice-versa. However, the alternative bill 
presentment and payment system 96 and its subscribers would not 
receive any of the benefits of the messaging functionality 
provided by the present system 50. Only the minimum amount of 
functionality would be provided. That is, the partner message 
interface 38 would only provide what is required to present 
bills through the alternative bill presentment and payment 
system 96, and not offer any of the advantages provided by the 
present system 50. The goal being to have the billing entity 56 
encourage all of its subscribers to access bills through the 
present system 50. 

It should be noted that the EPCS entity 58 will typically 
require the capabilities of a billing entity 56 in order to 
present bills to and from the alternative bill presentment and 
payment system 96. 

As previously described, a customer care message interface 
40 defines messages that are used to communicate and query data 
between a given distributed database entity 30 and a customer 
care entity. As also previously described, each customer care 
message interface 4 0 can be implemented using any number of 
existing message-based communication systems, or with 
proprietary messaging software on a private network or intranet. 
Furthermore, the message specification or file format can be 
either standard (i.e., open) or proprietary. 

Referring to Figure 8, there is shown a schematic diagram 
of the versatile electronic bill presentment and payment system 
50, along with some associated customer care entities. The 
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associated customer care entities comprise a user entity self 
service center 100, a banking entity customer service center 
102, a billing entity customer service center 104, and an EPCS 
customer service center 106. The communications between the 
5 various database entities and their associated customer care 
entities are performed over interconnections 108, which can be 
electrical wire, optical fiber, or microwave-based 
interconnections . 

Depending upon the nature of the presentation technology 
10 being used (e.g., a "fat" client, an HTML browser client, or a 
Java client), the user entity 52 may need to process a customer 

O care message in order to communicate with a customer care entity 

S such as, for example, the user entity self service center 100. 

El The user entity self service center 100 could be, for example, a 

C|5 self service diagnostic tool. 

CP The banking entity 54 will process customer care messages 

T from a customer care entity such as, for example, the banking 
5 entity customer service center 102. A customer care message may 
t; be a request for data or a request to modify existing data. The 
Jao banking entity 54 will process such customer care messages by 
S providing the requested data or providing a confirmation that 
the existing data has been modified, respectively, to the 
banking entity customer service center 102. The banking entity 
customer service center 102 could be, for example, a third party 
25 telemarketing group that is allowed access to banking and 
overall system data in order to provide feedback to system 
subscribers . 

The billing entity 56 will process customer care messages 
from a customer care entity such as, for example, the billing 
30 entity customer service center 104. A customer care message may 
be a request for data or a request to modify existing data. The 
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billing entity 56 will process such customer care messages by 
providing the requested data or providing a confirmation that 
the existing data has been modified, respectively, to the 
billing entity customer service center 104. The billing entity 
customer service center 104 could be, for example, a third party 
telemarketing group that is allowed access to billing and 
overall system data in order to provide feedback to system 
subscribers . 

The EPCS entity 58 will process customer care messages from 
a customer care entity such as, for example, the EPCS entity 
customer service center 106. A customer care message may be a 
request for data or a request to modify existing data. The EPCS 
entity 58 will process such customer care messages by providing 
the requested data or providing a confirmation that the existing 
data has been modified, respectively, to the EPCS entity 
customer service center 106. The EPCS entity customer service 
center 106 could be, for example, a third party telemarketing 
group that is allowed access to event and overall system data in 
order to provide feedback to system subscribers. 

It should be noted that all of the customer care entities 
described above could be consolidated into a centralized 
customer service center 110, as shown in Figure 9. In such a 
scenario, each of the database entities would process customer 
care messages to and from the centralized customer service 
25 center 110 similar to as described above. The communications 
between the various database entities and the centralized 
customer service center 110 would be performed over 
interconnections 112, which can be electrical wire, optical 
fiber, or microwave-based interconnections. 
30 Referring to Figures 10-15, there are shown flowchart 

diagrams of data and message flows between the various entities 
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within the system 50. These flowchart diagrams assume that the 
user entity 52 is an HTML browser client, the banking entity 54 
is the primary point of presence for a subscriber to the system 
50, the billing entity 56 controls bill presentment, and the 
5 EPCS entity 58 controls bill payment. 

In Figure 10, a subscriber at the user entity 52 accesses 
the web site of the banking entity 54 in step 200. In return, 
the banking entity 54 presents a branded interface to the user 
entity 52, including a sign-on request prompt in step 202. 
10 Figure 16 shows an example of such a branded interface 120, 
wherein the sign-on request prompt includes a username field 122 
rl and a password field 124. 

fl In Figure 11, the user entity 52 submits a sign-on request 

Sj with authentication credentials in steps 204. The banking 
CJs entity 54 messages the EPCS entity 58 with the authentication 
ff 1 credentials of the subscriber and the event is logged in step 

5 s3 

J 206. The EPCS entity 58 provides a security ticket to the 
3 banking entity 54 in step 208. The banking entity 54 delivers 

O the security ticket to the user entity 52 and presents its "home 
^20 page" to user entity 52 in step 210. Figure 17 shows an example 
J3 of such a home page 130, which includes a "view bills" icon 132, 

a "view checking account" icon 134, and a "view savings account" 

icon 136. 

It should be noted that either the EPCS entity 58 or the 
25 banking entity 54 could perform the authentication procedure, 
but in either case the event is still logged in the event 
tracking database . 

In Figure 12, the subscriber selects the "view bills" icon 
132 in step 212. The banking entity 54 messages the EPCS entity 
30 58 with an aggregation data request and the event is logged in 
step 214. The EPCS entity 58 presents aggregation data of new 
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bill availability to user entity 52 in step 216. Figure 18 
shows a first modified home page 140 having an EPCS entity frame 
142 presenting the new bill availability data, which includes an 
"electric bill" icon 144, a "gas bill" icon 146, a "phone bill" 
5 icon 148, a "cable bill" icon 150, a "credit card bill" icon 
152, and an "all bills" icon 154 which allows all bills to be 
presented simultaneously, albeit in separate frames. 

In Figure 13A, the subscriber selects the "gas bill" icon 
146 and is linked to the billing entity 56 along with the 
10 security ticket in step 218. The billing entity 56 messages the 
EPCS entity 58 to log the "view bill" request event in step 220. 
^ The billing entity 56 presents detailed bill data to the user 
entity 52 in step 222. Figure 19 shows a second modified home 
jS page 160 having a billing entity frame 162 presenting the 
J|5 detailed bill data, which includes the subscriber name, 
CP subscriber address, account number, usage, and cost, and a "pay 
^ bill" icon 164. 

S In Figure 14, the subscriber selects the "pay bill" icon 

Fl 164 and messages the EPS entity 58 with a forward dated pay bill 
\20 request so the event is logged in step 224. The EPS entity 58 
J3 messages the billing entity 56 with a pay bill request 

notification along with a bill identification number in step 

226. 

In Figure 15, the EPS posts a debit with the banking entity 
25 54 and the event is logged in step 228. The EPS entity 58 then 
remits a payment to the billing entity 56 and the event is 
logged in step 230. 

Figure 13B can be substituted for Figure 13A in the above- 
described sequence of flowchart diagrams to show how detailed 
30 bill data can be provided by the established billing aggregator 
94 thru the partner message interface 38 of the billing entity 
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56. In Figure 13B, the subscriber again selects the "gas bill" 
icon 146 and is linked to the billing entity 56 along with the 
security ticket in step 232. The billing entity 56 again 
messages the EPCS entity 58 to log the "view bill" request event 
5 in step 234. However, in this case, detailed bill data is 
available only from the established billing aggregator 94. 
Thus, the billing entity 56 accesses the established billing 
aggregator 94 through its partner message interface 38 in step 
236. In response, the established billing aggregator 94 
10 provides detailed bill data to the billing entity 56 in step 
238. The billing entity 56 then presents the detailed bill data 
to the user entity 52 in step 240. 
C° It should be noted that, in an alternative embodiment, the 

m established billing aggregator 94 could present the detailed 
Hs bill data directly to the user entity 52. 

fjf* Figure 13C can be substituted for Figure 13A in the above- 

^ described sequence of flowchart diagrams to show how detailed 
O bill data can be provided by the alternative bill presentment 
fl and payment system 96 thru the partner message interface 38 of 
*$0 the EPCS entity 58. In Figure 13C, the subscriber selects the 
5 "gas bill" icon 14 6 and is linked back to the EPCS entity 58 
along with the security ticket and the event is logged in step 
242. In this case, detailed bill data is available only from 
the alternative bill presentment and payment system 96. Thus, 
25 the EPCS entity 58 accesses the alternative bill presentment and 
payment system 96 through its partner message interface 38 in 
step 244. In response, the alternative bill presentment and 
payment system 96 provides detailed bill data to the EPCS entity 
58 in step 246. The EPCS entity 58 then presents the detailed 
30 bill data to the user entity 52 in step 248. 
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It should be noted that, as previously described, the EPCS 
entity 58 will typically require the capabilities of a billing 
entity 56 in order to present bills to and from the alternative 
bill presentment and payment system 96. Alternatively, it 
5 should be noted that detailed bill data can be provided by the 
alternative bill presentment and payment system 96 thru the 
partner message interface 38 of the billing entity 56 in a 
manner similar to that as described in Figure 13B. 

Referring to Figure 20, there is shown a flowchart diagram 
10 of data and message flows between the centralized customer 
service center 110 and the various entities within the system 
50. A subscriber 170 contacts the centralized customer service 
center 110 regarding a bill payment in step 250. The 
Id centralized customer service center 110 accesses the event 
2ft tracking database in the EPCS entity 58 to see if a view bill, 
2? P a Y bill, remit payment, or debit posting event has been logged 
JE in step 252 0 If more detailed information regarding, for 
example, the '^sting of a debit for a bill, the centralized 
CI customer service!*, center 110 can access the database component 32 
5b associated with v 4he banking entity 54, as shown in step 254. 
S Similarly, if mof%* detailed information regarding, for example, 
the remitting of a payment for a bill, the centralized customer 
service center ll^ can access the database component 32 
associated with the billing entity 56, as shown in step 256. It 
25 should be noted that, '^though not shown, the EPCS entity 58 can 
log all of the above-described accesses performed by centralized 
customer service center 110. 

As is apparent from the foregoing description, the system 
50 allows a subscriber to interact directly with individual 
30 billers while retaining the benefits of interacting with a 
single aggregator such as, for example, the ability to retain a 
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10 



single authentication and log-in procedure and a common bill 
presentation framework. The system 50 also allows a subscriber 
to retain the benefits of interacting with a single aggregator 
while allowing the billers and banks to retain certain 
preferences such as, for example, the ability to retain control 
of subscriber-related data and a communication channel with each 
subscriber. 

As discussed above with reference to Figures 14 and 15, 
when, after reviewing billing information, detailed or 
otherwise, at the biller entity site, the user selects "pay 
bill", the user is directed to the EPCS which communicates with 
the applicable billing and banking entities to process the 
J payment. To perform this function, the database component 32 
«J associated with the EPCS entity 58 must be kept aware of the 
%|5 total amount of each available bill for a user. Accordingly, 
each billing entity must provide bill summary information, 
HF including at least the total bill amount, for each available 
O bil1 to the aggregator database, which is preferably but not 
m necessarily located at the EPCS entity, as has been previously 
§J0 discussed. Thus, the database component 32 of the EPCS entity 
Jj 58 stores bill summary information for each available bill for 
each user which is accessed and used by the EPCS to process 
payment responsive to the receipt of the user's "pay bill" 
request message. 

As will be understood, if the total bill amount stored in 
the database component 32 of the EPCS entity 58 does not match 
the total bill amount presented to the user by the billing 
entity, serious payment problems could arise. For example, if 
in reviewing the detailed electronic bill information maintained 
by the billing entity, the user is allowed to dispute a charge 
and to have the disputed charge removed from the bill pending 
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resolution of the dispute, the bill may be adjusted by the 
billing entity while the user remains on-line. If this 
adjustment to the total bill amount is not conveyed to the EPCS 
in real time, should the user select "pay bill" during the 
5 session, the total bill amount, as reflected at the billing 
entity, will be less than the total bill amount stored in the 
database component 32 of the EPCS entity 58. Thus, the EPCS 
would process the requested payment in the wrong amount. 

Further, some billers, particularly utility companies, are 
10 now offering discounts to customers who perform, and provide to 
the company, monthly meter readings. The utility company 
n generates the customer's bill based upon the meter reading 
ffl provided by the customer. Receiving this information via a 
fjk digital communication, such as an Internet communication, 
J15 facilitates the processing of the information by the company 
m while the user remains on-line. Hence, the user can provide a 
J 8 meter reading, the billing entity can generate a bill based upon 
O the meter reading, and the detailed bill information can be 
Q presented to the user all in a single on-line session between 
^jo the user and the billing entity. If this generated total bill 
%0 amount is not conveyed to the EPCS in real time, the user either 
would not be allowed to direct payment of the bill by selecting 
"pay bill" during the on-line session, or would have the 
processing of its payment directive delayed, since the EPCS 
25 would not be privy to the total bill amount generated by the 
billing entity at the time of the payment request. 

Figure 21 depicts the message flow in an alternative 
electronic billing system which is capable of updating bill 
summary information stored at the EPCS in real time, and hence 
30 providing dynamically updateable electronic bill summary 
information to a subscriber. The system ensures consistency 
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between bill information at the EPCS and at the biller. This 
feature can be particularly important in facilitating the 
electronic presentment and payment of bills. 

As shown, the subscriber selects the "view bills" icon 1132 
in step 1212. The banking entity 54 messages the EPCS entity 58 
with an aggregation data request and the event is logged in step 
1214. The EPCS entity 58 presents aggregation data of new bill 
availability to user entity 52 in step 1216. 

An EPCS entity frame 1140A presenting the new bill 
availability data for a subscriber is shown in Figure 22A. 
Figure 22A is similar to Figure 18, except that a notification 
is provided to the user that the electric and gas bills require 
a meter reading. More particularly, the available bills shown 
on screen 1140A include an "electric bill" icon 1144, a "gas 
bill" icon 1146, a "phone bill" icon 1148A, a "cable bill" icon 
1150A, a "credit card bill" icon 1152A, and an "all bills" icon 
1154 which allows all bills to be presented simultaneously, 
albeit in separate frames. The electric and gas bills are shown 
with an associated notation reminding the subscriber that he/she 
must provide the applicable meter reading in order to obtain 
these bills from the biller 56. 

Alternatively, an EPCS entity frame 1140B could be used to 
present the new bill availability data for a subscriber as shown 
in Figure 22B. Figure 22B is similar to Figure 22A except that 
summary information, including the total bill amount, is 
provided for some of the available bills. More particularly, 
the available bills shown with the total bill amount on screen 
1140B include a "phone bill" icon 1148B, a "cable bill" icon 
1150B, and a "credit card bill" icon 1152B. Each of these bills 
also has a "pay bill" icon 1155, which allows the user to pay 
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that bill directly from the screen 1140B by simply clicking-on 
the icon for the bill. 

In Figure 23A, which is similar to Figure 13A, the 
subscriber selects the "gas bill" icon 1146 from screen 1140A or 
5 1140B and is linked to the billing entity 56 along with the 
security ticket in step 1218A. The billing entity 56 messages 
the EPCS entity 58 to log the "view bill" request event in step 
1220A. The billing entity 56 first presents a query requesting 
the gas meter reading from the user entity 52 in step 1221A. 
10 The user entity 52 responds to the request in step 1222A by 
messaging the gas meter reading to the billing entity 56. The 
„ billing entity 56 processes the gas meter reading to generate 
*B the detailed bill data in real time while the user entity 

j- ij 

m remains on-line. 

/"{l5 The generated detailed bill data is presented to the user 

fll entity 52 in step 122 3A. As shown in Figure 2 4 A, the generated 
detailed bill information is presented on a home page 1160A, 
y having a billing entity frame 1162A which includes the generated 
O detailed gas bill data for the subscriber. The home page 1160A 
rjo includes, within frame 1162A, the subscriber name, subscriber 
address, account number, the total cost or amount of the bill, a 
"pay bill" icon 1164A and a "home" icon 1167A. 

In one alternative operational sequence, the billing entity 
56 messages the total amount of the generated gas bill to the 
25 EPCS 58 in real time while the user entity 52 remains on-line in 
step 1224A. The detailed gas bill data is stored in the 
database component 32 of the billing entity 56. The total gas 
bill amount is stored in the database component 32 of the EPCS 
58. Hence, the subscriber can now click on the "pay bill" icon 
30 1164A to be hyperlinked back and to transmit a pay request 
message to the EPCS 58. The EPCS will have the generated bill 
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amount necessary to proceed with the payment, as has been 

previously described, in accordance with the pay instruction. 

The subscriber can alternatively click on the "home" icon 1167A 

to reconnect to the EPCS 58 and again view screen 1140A or 
5 1140B. In this viewing the screen 1140A or the screen 1140B, as 

applicable, would be modified so as to reflect the total gas 

bill amount due. 

More particularly, the modified screen 1140A no longer 

includes the indication shown in Figure 22A that a gas meter 
10 reading is required. Rather, the EPCS 58, responsive to the 

receipt of the total bill amount and in real time, generates a 
jp revised screen 1140A for presentation to the subscriber which 
* reflects the total gas bill amount computed by the billing 
fij entity 56 based on the gas meter reading provided by the user 
C|15 entity 52. The modified screen 1140B also eliminates the 
^ indication shown in Figure 22B that a gas meter reading is 
s required and displays the computed total gas bill amount and an 
if associated "pay bill" icon. 

& In a preferred alternative operational sequence, user 

lr£0 entity 52 rather than billing entity 56 messages the computed 
total gas bill amount to the EPCS 58. More particularly, after 
being presented with the generated bill, the subscriber clicks 
on either the "pay bill" icon 1164A or the "home" icon 1167A and 
is hyperlinked back to the EPCS 58. A fat URL is used to 
25 address the EPCS 58, allowing the generated total bill amount to 
be included in the URL used to hyperlink back to the EPCS. Thus, 
the EPCS 58 receives the generated bill amount from the 
subscriber, either with or without an instruction to pay the 
bill, in real time while the user entity 52 remains on-line in 
30 step 1224A' . Here again, the detailed gas bill data is stored 
in the database component 32 of the billing entity 56 and the 
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total gas bill amount is stored, at least temporarily, in the 
database component 32 of the EPCS 58. 

If the subscriber has clicked on the "home" icon 1167A, the 
subscriber can again view screen 1140A or 1140B. In this 
5 viewing the screen 1140A would be modified to eliminate the 
indication shown in Figure 22A that a gas meter reading is 
required. As previously discussed, the EPCS responds to the 
receipt of the total bill amount by generating, in real time, a 
revised screen 1140A for presentation to the subscriber which 
10 reflects the biller computed total bill amount based on the user 
provided gas meter reading. The screen 1140B is modified to 
^ eliminate the indication that a gas meter reading is required, 
M3 as shown in Figure 22B, and also to display the total gas bill 
m amount and an associated "pay bill" icon. 

Ji5 In Figure 23B, the subscriber selects the "phone bill" icon 

m 1140A or 1140B to view the phone bill and is linked to the 
J"' billing entity 56 along with the security ticket in step 1218B. 
O The billing entity 56 messages the EPCS entity 58 to log the 
O "view bill" request event in step 1220B. The billing entity 56 
r 5o presents the detailed bill data, which is stored in the database 
S component 32 of the billing entity 56, to the user entity 52 in 
step 1221B. 

Turning to Figure 24B, a home page 1160B has a billing 
entity frame 1162B presenting the detailed phone bill data to 

25 the subscriber. The home page 1160B includes, within frame 
1162B, the subscriber name, subscriber address, account number, 
a breakout of the individual calls being charged 1166A, 1166B 
and 1166C, and the associated cost of each call, the total bill 
amount 1168, a "pay bill" icon 1164B, a "home" icon 1167B and 

30 respective "dispute" icons 1165A, 1165B and 1165C. 
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The subscriber responds to the detailed phone bill data 
presented in step 1221B by clicking on the dispute icon 1165B. 
This results in the user entity 52 messaging the billing entity 
56 with an indication that the charge for call 1166B is disputed 
5 by the subscriber. The billing entity 56 processes the dispute 
message to remove the disputed charge and to generate revised 
detailed bill data in real time while the user entity remains 
on-line . 

The generated revised detailed bill data is presented to 
10 the user entity 52 in step 1223B. As shown in Figure 24C, the 
home page 1160B has the billing entity frame 1162B updated to 
f=r i; present the detailed revised phone bill data to the subscriber. 
^ The home page 1160B therefore now includes, within revised frame 
fjo 1162B, the breakout of the individual calls being charged, i.e. 
Jt5 calls 1166A and 1166C, with their associated cost, and the 
m revised total amount 1168A based on only these calls. The 

ks;:; 

revised frame 1162B also reflects that the cost of call 1166B is 
disputed. 

g In one alternative operational sequence, the billing entity 

1^0 56 messages the revised total amount of the phone bill to the 
C* EPCS 58 in real time, while the user entity 52 remains on-line, 
in step 1224B. The revised detailed phone bill data is stored 
in the database component 32 of the billing entity 56. The 
revised total phone bill amount is stored in the database 
25 component 32 of the EPCS 58. Hence, the subscriber can now 
click on the "pay bill" icon 1164B to be hyperlinked back and to 
transmit a pay request message to the EPCS 58. The EPCS has the 
generated revised bill amount necessary to proceed with the 
payment in accordance with the instruction, as has been 
30 previously described. The subscriber can alternatively click on 
the "home" icon 1167B to reconnect to the EPCS 58 and again view 
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screen 1140A or 1140B, as applicable. In this viewing the 
screen 1140A would remain as shown in Figure 22A but the screen 
1140B would be modified. 

More particularly, the modified screen 1140B displays the 
5 revised total phone bill amount. This is accomplished by the 
EPCS 58 , responsive to the receipt of the revised total bill 
amount and in real time, generating revised screen 1140B for 
presentation to the subscriber so as to reflect the computed 
revised total gas bill amount. 
10 In a preferred alternative operational sequence, user 

entity 52 rather than billing entity 56 messages the computed 
p :! revised total phone bill amount to the EPCS 58. More 
<{ particularly, after being presented with the generated revised 
m bill, the subscriber clicks on either the "pay bill" icon 1164B 
/is or the "home" icon 1167B and is hyperlinked back to the EPCS 58. 
jn As discussed above, a fat URL is used to address the EPCS 58. 
J This allows the generated revised total bill amount to be 
%J included in the URL used to hyperlink back to the EPCS. Thus, 
Q the EPCS 58 receives the generated revised bill amount from the 
\£Q subscriber, either with or without an instruction to pay the 
J3 bill, in real time while the user entity 52 remains on-line in 
step 1224B' . Here again, the revised detailed phone bill data 
is stored in the database component 32 of the billing entity 56 
and the revised total phone bill amount is stored, at least 
25 temporarily, in the database component 32 of the EPCS 58. 

If the subscriber has clicked on the "home" icon 1167B, the 
subscriber can again view screen 1140A or 1140B. In this 
viewing the screen 1140A is unmodified. On the other hand, the 
screen 1140B is modified to display the revised total phone bill 
30 amount. As previously discussed, this is accomplished by the 
EPCS 58 generating, responsive to the receipt of the revised 
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total bill amount and in real time, a revised screen 1140B for 
presentation to the subscriber which reflects the biller 
computed revised total phone bill amount. 

At this point it should be noted that while the foregoing 
detailed description was directed to an electronic bill 
presentment and payment technique, any number of system types 
can employ the distributed database entities 30 to facilitate 
distributed data accessing within a network in accordance with 
the present invention. 

The present invention is not to be limited in scope by the 
specific embodiments described herein. Indeed, various 

modifications of the present invention in addition to those 
described herein, will be apparent to those of skill in the art 
from the foregoing description and accompanying drawings. Thus, 
such modifications are intended to fall within the scope of the 
appended claims. 
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CLAIMS 

What is claimed is: 

1 1. An electronic bill payment network, comprising: 

2 a plurality of user network stations associated with a 

3 plurality of different users, a first of the plurality of user 

4 network stations being associated with a first of the plurality 

5 of different users and operable to transmit, in real time, 

6 information relevant to an amount of an available bill and an 

7 instruction to pay the available bill; 

8 a plurality of biller network stations associated with a 

9 plurality of different billers, a first of the plurality of 

10 biller network stations being associated with a first of the 

11 plurality of different billers and operable, in real time, to 

12 receive the transmitted information and to determine the amount 

13 of the available bill based upon the received information; and 

14 a central network station operable, in real time, to 

15 receive the determined amount of the available bill and the 

16 transmitted pay instruction, and to direct payment of the 

17 determined amount of the available bill based upon the 

18 transmitted instruction to pay that available bill. 
1 

1 2. A network according to claim 1, wherein: 

2 the central network station is further operable to transmit 

3 bill availability information identifying a plurality of 

4 available bills of the plurality of different billers for the 

5 plurality of different users, including at least two of the 

6 plurality of available bills for the first user; and 
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7 the first user network station is further operable to 

8 receive the transmitted bill availability information, to select 

9 the available bill from the identified at least two available 

10 bills, and to transmit a request for the available bill based 

11 upon the selection. 
1 

13. A network according to claim 2, wherein the bill 

2 availability information identifies available bills without 

3 identifying an amount of each of the bills. 
1 

1 4. A network according to claim 2, further comprising: 

f ,,2 a database configured to store the bill availability 

;|I3 information so as to further identify those of the identified 
ffl 4 available bills which require information relevant to the amount 
of those identified available bills. 

Cm* 

5. A network according to claim 4, wherein the database is 
02 further configured to store the determined amount. 
Ql 

fZl 6. A network according to claim 1, wherein the transmitted 
J3 2 information is indicative of a quantity of product used. 
1 

17. A network according to claim 6, wherein the transmitted 

2 information is a meter reading. 
1 

18. A network according to claim 1, wherein the transmitted 

2 information is indicative of a disputed portion of a previously 

3 determined amount of the available bill. 
1 

1 
1 
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1 9. A network according to claim 1, wherein: 

2 the first biller network station is further operable, in 

3 real time, to transmit the available bill including a previously 

4 determined amount, and the determined amount of the available 

5 bill represents an adjustment to the previously determined 

6 amount . 
1 

1 10. A method of paying electronic bills, comprising the steps 

2 of: 

3 transmitting, in real time, information relevant to an 

4 amount of an available bill, from a first network location; 

^5 determining, in real time, the amount of the available bill 

^6 based upon the transmitted information, at a second network 

g| 7 location; 

./J 8 receiving, in real time, the determined amount, at the 

B\ 9 first network location; 

J 10 transmitting, in real time, an instruction to pay the 

^fll determined amount, from the first network location; 

Q12 receiving, in real time, the determined amount and the 

"j3 transmitted pay instruction, at a third network location; and 

JJl4 directing payment of the determined amount of the available 

15 bill based upon the transmitted pay instruction, from the third 

16 station. 
1 

1 11. A method according to claim 10, further comprising the steps 

2 of: 

3 transmitting, in real time, bill availability information 

4 identifying a plurality of available bills of a plurality of 

5 different billers, from the third network location; 

6 selecting, in real time, the available bill from the 

7 identified plurality of available bills; 
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8 transmitting, in real time, a request for the available 

9 bill based upon the selection; and 

10 transmitting, in real time, a request for the relevant 

11 information responsive to the transmitted request for the 

12 available bill; 

13 wherein the relevant information includes a quantity of 

14 product used and is transmitted responsive to the transmitted 

15 request for relevant information. 
1 

1 12. A method according to claim 11, wherein the quantity of 

2 product used is represented by a meter reading. 

€h 13. A method according to claim 10, further comprising the 

m2 steps of: 

; ^3 transmitting, in real time, bill availability information 

§14 identifying a plurality of available bills of a plurality of 

7*5 different billers, from the third network location; 

C ; 6 selecting, in real time, the available bill from the 

£37 identified plurality of available bills; 

\T 8 transmitting, in real time, a request for the available 

i|J 9 bill based upon the selection; and 

10 transmitting, in real time, the available bill, including a 

11 previously determined amount of the available bill, responsive 

12 to the transmitted request for the available bill, from the 

13 second location; 

14 wherein the relevant information includes a requested 

15 modification to the previously determined amount. 
1 

1 14. A method according to claim 10, further comprising the 

2 steps of: 
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3 storing, in a database, bill availability information 

4 identifying a plurality of available bills of a plurality of 

5 different billers and those of the identified plurality of 

6 available bills which require information relevant to the amount 

7 of those available bills. 

8 transmitting, in real time, the stored bill availability 

9 information, from the third network location; and 

10 selecting, in real time, the available bill from the 

11 plurality of available bills identified in the transmitted bill 

12 availability information, at the first location; 

13 wherein the available bill is one of those of the plurality 
^14 of available bills requiring information relevant to the bill 
«ft5 amount . 

5 1 

J l 1 15. A method according to claim 14, further comprising the step 

312 of: 

J" 3 storing, in real time, the received amount in the database. 

O 1 

Q 1 16. A electronic bill payment system, comprising: 

2 a database configured to store bill availability 

m 3 information identifying available bills of a plurality of 

4 different billers for a plurality of different users; 

5 a processor configured (i) to receive a real time network 

6 communication of an amount of one of the available bills 

7 identified in the stored bill availability information for a 

8 first of a plurality of different users from a first of the 

9 plurality of different billers and a real time network 

10 communication of an instruction to pay the available bill from 

11 the first user, (ii) to transmit, in a real time network 

12 communication, a directive to pay the amount of the available 

13 bill based upon the received pay instruction, and (iii) to store 
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14 the amount in the database in association with the bill 

15 availability information identifying the available bill. 
1 

1 17. A system according to claim 16, wherein: 

2 the processor is further configured to (i) receive a real 

3 time network communication requesting bills of the first user, 

4 (ii) to transmit a real time network communication of the stored 

5 bill availability information identifying available bills, 

6 including the available bill, for the first user, and (iii) to 

7 receive a real time network communication indicative of the 

8 available bill having been requested from the first biller. 



t j l 18. A system according to claim 16, wherein: 

2 the database is further configured to store the bill 

3 availability information so as to further identify those of the 

4 identified available bills which require information relevant to 
J 5 the amount of those bills; and 

5 6 the available bill is one of those of the plurality of 

Q 7 available bills further identified as requiring relevant 

% 8 information. 

1 19. A system according to claim 16, wherein: 

2 the database is further configured to store a previously 

3 received amount of the available bill; and 

4 the received amount of the available bill is substituted 

5 for the previously received amount in the database. 
1 

1 20. An article of manufacture for paying bills electronically, 

2 comprising: 

3 a computer readable storage medium; and 



51 



Docket No.: 33500-019D 
File No. : 20734D 
Client No. : BOSS-D 



4 computer programming stored on the medium and configured to 

5 be readable from the medium by a computer processor and thereby 

6 cause the processor to operate in real time so as to: 

7 receive a communication of an amount of an available 

8 bill of a first of a plurality of different billers for a first 

9 of a plurality of different users determined by the first 

10 biller; 

11 receive a communication of an instruction of the first 

12 user to pay the available bill; and 

13 generate a directive to pay the received 

14 amount of the available bill based upon the received pay 
J5 instruction. 

ml 21. An article of manufacture according to claim 20 , wherein 

2 the computer programming is further configured to cause the 

fj!3 processor to operate so as to: 

y 4 to store the received amount in a database, 

O l 

rj; 1 22. An article of manufacture according to claim 21, wherein 

^2 the amount is stored in the database so as to replace a 

J3 3 previously determined amount of the available bill previously 

4 stored in the database. 

1 

1 23. An article of manufacture according to claim 20, wherein 

2 the computer programming is further configured to cause the 

3 processor to operate in real time so as to: 

4 receive a communication requesting bills of the first user; 

5 transmit bill availability information identifying 

6 available bills, including the available bill, for the first 

7 user responsive to the received communication requesting bills; 

8 and 
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receive a communication indicating receipt of a request for 
the available bill from the first biller. 

24. An article of manufacture according to claim 23, wherein 
the transmitted bill availability information includes an 
indication that the available bill requires information relevant 
to the amount of the available bill. 

25. An article of manufacture according to claim 20, wherein 
the received amount of the available bill represents an 
adjustment to a previously received amount of the available 
bill. 
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ABSTRACT OF INVENTION 

An electronic bill payment network includes a plurality of 
user network stations associated with different users, a 
plurality of biller network stations associated with different 
billers, and a central network station. A first user station 
operates, in real time, to transmit information relevant to an 
amount of an available bill and an instruction to pay the 
available bill. A first biller station operates, in real time, 
to receive the transmitted information and to compute the amount 
of the available bill based upon the received information. The 
central network station operates to receive the computed amount 
of the available bill and the transmitted pay instruction, and 
to direct payment of the computed amount of the available bill 
based upon the transmitted instruction to pay that bill. 
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